Chip 1996 April/CHIP 1996 aprilis (CD06).zip/CHIP_CD06.ISO/hypertxt.arj/9304/SSTOR202.CD

Text File | 1995-04-19 | 29KB | 496 lines

          @VSzupersztár?!@N

          @VSuperStor 2.00 -- II.@N

          Végre   eljutott   hozzánk   a  SuperStor  röptömörítô  2.00
          verziója.    Elôzô    számunkban   a   RAM-lemezekkel   való
          kínlódásnál hagytuk abba.



          Sokat  küszködtünk  a  problémával,  míg  sikerült megoldást
          találni.  Ha  a  RAM-drive  fix  méretû  (ez  többnyire  így
          szokott   lenni),   akkor   hozzuk   létre  rajta  @Kkézzel@N  a
          tömörített  lemezt,  vagyis  kérjünk  mountolható  SuperStor
          meghajtót.  A  hordozó  RAM-lemezen  (ha  üres  volt)  ekkor
          egyetlen   file   lesz,  a  hordozó  file.  Ezt  mentsük  el
          valamelyik    hagyományos,   off-line   tömörítôvel   archív
          file-ba,  onnan  bármikor  visszaállíthatjuk,  visszaállítás
          után pedig a MOUNT.EXE programmal mountolhatjuk.

          Nem  éppen  elegáns megoldás, de mûködik -- nem úgy, mint az
          SSUTIL     ideillô     részlete.    5000    Kbyte-os,    DOS
          RAMDRIVE.SYS-szel  készített  RAM-lemezen a fenti eljárással
          maximális  méretû  mountolható  meghajtót  készítve,  az azt
          hordozó  file-t  ARJ-vel  tömörítve 2170 byte-os, tehát pici
          archív  file-t  kaptunk.  Ehhez  persze  az  is kell, hogy a
          mountolható  meghajtó  elkészítése  elôtt semmit ne írjunk a
          RAM-lemezre,   lehetôleg   közvetlenül   a  gép  indításakor
          készítsük   el   a   mountolható   meghajtót.   A  RAM-lemez
          esetleges  átméretezése  után sajnos meg kell ismételnünk az
          eljárást,    figyelni    kell    a   RAM-lemez   betûjelének
          megváltozására  is,  s  módosítanunk  kell a megfelelô batch
          file-t.

          RAM-lemezek  röptömésénél  a  SuperStor  egyetlen  elônye  a
          Stackerrel    szemben   az,   hogy   nemcsak   512   byte-os
          szektorméretû  RAM-lemezre képes röptömött meghajtót kreálni
          -- hátránya pedig, jól látszik, bôven van.


           @VKompatibilitás@N

          A  SuperStor kézikönyve közli az ismert inkompatibilitásokat
          és   megszorításokat.  A  megszorításokat  indokolja  is  --
          például  a  DOS 3.31 elôtti verziói nem képesek 32 Mbyte-nál
          nagyobb   lemezpartíciókat   kezelni,  ez  a  megszorítás  a
          röptömörített   meghajtókra  is  áll.  Az  egyetlen  feltûnô
          inkompatibilitás  a Norton Utilities és az MS DOS 5.0 QU.EXE
          illetve   UNDELETE.EXE   (törölt   file-okat   visszaállító)
          programjának   hatástalansága  a  SuperStor  meghajtókon  --
          helyette   a   DR  DOS  6.0x  UNDELETE-jét  és  a  PC  Tools
          file-visszaállító  funkcióját  javasolják használni. A többi
          inkompatibilitás  (például  Windows  3.1  permanens swapfile
          elhelyezési  megszorítások,  a  Spinrite lemezdiagnosztizáló
          és  -javító  program  csak  a  röptömött meghajtókat hordozó
          lemezeken  használható)  minden  röptömörítônél  -- elvükbôl
          következôen  --  azonos.  A  kézikönyv  szerint  a SuperStor
          2.00  drivere  az  1.3g-nél  nem  régebbi verziójú SuperStor
          meghajtók  esetén  rátelepíthetô  a  régire.  Ezt  --  mivel
          nekünk   csak   régebbi  drivereink  voltak  --  nem  tudtuk
          ellenôrizni.

          A  használat  során  az említetteken kívül nem találtunk más
          inkompatibilitást.  Azzal  azonban  számolni  kell,  hogy --
          mint  minden röptömörítô -- jókora program, s 286-os AT-ken,
          XT-ken  a  memóriából többnyire menthetetlenül elfogyaszt 45
          Kbyte-ot.  286-os  AT-ken  még  segíthet  ezen  a  QRAM,  az
          UMBDRIVER,  az EXTENDER vagy más memóriavarázsló program, de
          az  XT-ken  reménytelen  a  helyzet.  A  Stacker  2.0x, 3.00
          verzióival  ellentétben  a  SuperStornak  egyetlen része sem
          rakható  EMS-be  --  olykor  ez  is  hátrány,  bár  386SX és
          afeletti  gépeken  még  nem kerültünk memóriaszûkébe, mindig
          sikerült    a    felsô    (upper)   memóriába   pakolni   az
          eszközmeghajtókat és a TSR programokat.

          Érdemes  megfogadni  a  kézikönyv  tanácsát: az SSTORDRV.SYS
          meghajtóprogram      CONFIG.SYS-beli      indításakor      a
          @KDEVICEHIGH@N     (DR     DOS    6.0:    @KHIDEVICE@N)    parancsot
          óvatosan  használjuk  --  ha  az adott gépen a felsô (upper,
          640K  és  1M  közti) memória nem használható DMA-ra, akkor a
          gép  lefagy,  esetleg fut, de hibásan (ez az ára a SuperStor
          sebességének).  Az  SSTORDRV.SYS  felsô memóriába töltésekor
          hibás  futást  mi  nem tapasztaltunk, lefagyást öt gép közül
          egy esetben igen.


           @VRejtett lehetôségek és problémák@N

          Már   a   DR   DOS   6.0-beli   SuperStornál  feltûnt,  hogy
          meghajtóprogramjának  vannak  kapcsolói,  de ezeket a DR DOS
          dokumentációja  nem  ismerteti. Rendben, gondoltam, végül is
          ez  egy  licencelt változat, nyilván nem teljes értékû, csak
          az  alapvetô  lehetôségeket támogatja. A DR DOS (Novell DOS)
          6.01  SuperStorjánál  ezeket  a kapcsolókat már nem lehetett
          használni,  noha  az SSTORDRV.SYS file-ban továbbra is benne
          voltak  --  kiiktatva.  A  legérdekesebb  azonban az, hogy a
          teljes  SuperStor 2.00-ban lévô SYS file-nak is vannak olyan
          kapcsolói, amikrôl a kézikönyv egy szót sem szól.

          Sôt,    a    hordozható    superstorolt   floppykat   indító
          2XON.COM-ban  --  ami nem minden SuperStor opciót támogat --
          benne  vannak  azok  a hibaüzenetek is, amiket az általa nem
          támogatott  opciók  hibás beállításakor ír(na) ki. Fura. Bár
          nyilván  nem  foglalnak sok helyet, de teljesen feleslegesek
          (s  minden  röptömörített  floppyn elfogyasztják az említett
          kevés helyet).

          Nézzük  sorban.  A  @K/MAXSS@N  opciót  a 2XON is támogatja -- a
          leírás  nem  említi.  Ugyanígy  kimaradt a leírásból, hogy a
          2XON-nak   megadhatjuk   a   fô   SSTORDRV.SYS   meghajtónál
          használható       @K/MAXFRAGS@N,       @K/HIDMA@N,       @K/NOHI@N,@K/AUTO@N
          opciókat  is  --  bár  kétségtelen,  hogy  ezeknek itt nincs
          komoly szerepük (leírásuk megvan a kézikönyvben).

          A   @K/BUFSIZ@N   opciót  csak  az  SSTORDRV.SYS  ismeri,  de  a
          kézikönyv   hallgat  róla.  Alapértéke  8192,  de  megadható
          16|384   vagy   32|768  is.  Nem  dokumentálták  a  @K/MAXDBUF@N
          paramétert  sem,  amelynek  alapértéke a kézikönyv szerint 1
          (valójában   2),   de  2  és  8  közt  bármely  más  értéket
          megadhatunk   itt.   Ha   semmit  sem  rak(hat)unk  a  felsô
          memóriába,  akkor  a  SSTORDRV.SYS  alapbeállításban  46|016
          byte-ot,  szélsôséges  esetben  (/BUFSIZ=32|768  /MAXDBUF=8)
          325|104  byte-ot  emészt föl a memóriából. A BUFSIZ növelése
          nem  gyorsít,  így  e kapcsoló használatát nem javasoljuk. A
          MAXDBUF  növelése  azonban  meglepô eredménnyel járt -- lásd
          teszteredményeinket.

          Az  SSTOR.EXE  és  az  SSUTIL.EXE mûveletei parancssorból is
          meghívhatók.  E  lehetôségrôl  a  kézikönyv  semmit  nem  ír
          (csak  a  RAM-lemezrôl  szóló  részen  említ valamit -- mint
          írtuk,  hibásan).  Pedig  fontos  dologról  van  szó: ha nem
          tudjuk  az  alapvetô  karbantartási mûveleteket (ellenôrzés,
          információkérés  stb.)  egyszerûen  végrehajtani,  mindig be
          kell  mászni egy menürendszerbe, s például nem lehet berakni
          a   lemezellenôrzést   az   AUTOEXEC.BAT-ba,   hogy   minden
          gépindításkor végrehajtódjék.

          A   két   program   parancssori   lehetôségei  az  @KSSTOR  /?@N
          illetve   @KSSUTIL   /?@N   parancsokkal   kérdezhetôk   le.   A
          kézikönyv  a  menübeli  parancsok  ismertetésénél  leírja  a
          mûveletek  jelentését  --  a  parancssori lehetôségek egy az
          egyben megfelelnek azoknak.

          Ha  például  a  teljes  C:-t  röptömörítjük,  úgy,  hogy  az
          SSTORDRV.SYS  indítása után eltûnjön a hordozó DOS C:, akkor
          a  kézikönyv  a  CONFIG.SYS minden módosítása után javasolja
          az  SSUTIL.EXE  @KUpdate@N  menüpontjának  végrehajtását.  Ez  a
          mûvelet   a  módosított  CONFIG.SYS-t  átmásolja  a  hordozó
          meghajtóra,   a   benne   az  SSTORDRV.SYS  @Kelôtt@N  meghívott
          meghajtóprogramokat       úgyszintén,       méghozzá       a
          gyökérkönyvtárba,  függetlenül  attól,  hogy  azok egyébként
          hol  vannak  a röptömörített C:-n, s mindezekkel összhangban
          módosítja  a  CONFIG.SYS-t.  (A  módszer  megbukik,  ha  egy
          meghajtóprogram  más,  a  CONFIG.SYS-be be nem írt file-t is
          vár,  ilyen például a PCKWIK legtöbb verziója -- szóval a C:
          eltüntetését  jobb  kerülni.)  Az AUTOEXEC.BAT módosításakor
          nem  kell  @KUpdate@N,  mivel  az  AUTOEXEC.BAT indulásakor a C:
          már  úgyis  a  SuperStor által kezelt virtuális meghajtó, az
          AUTOEXEC.BAT  ott  pont  jó helyen van (a hordozó C:-n nincs
          is  rá  szükség  --  az  @KUpdate@N  sem másolja át). Ha már fut
          egy   alacsony  szinten  dolgozó  cache-program  (például  a
          HyperDisk),    akkor    az   @KUpdate@N   sikertelen   lesz   (a
          kézikönyv  hallgat  errôl,  a  jelenség  oka rejtély). Ezért
          cache   használata   esetén   az   @KUpdate@N-hez   a  következô
          mûveletsort    kell    elvégezni:    cache-t    kikapcsolni,
          @KUpdate@N,   utána   cache-t   ismét   be.   E   mûveletsor   a
          HyperDiskkel    (v4.51)   és   az   SSUTIL.EXE   parancssori
          meghívásával például a következôképpen néz ki:

           @KC:\HYPERDSK\HYPERDKC.EXE D@N
          @K@N
          @K C:\ADDSTOR\SSUTIL.EXE /U@N
          @K@N
          @K C:\HYPERDSK\HYPERDKC.EXE E@N

          A    lemezcache-programok    háttérben    író   üzemmódjának
          veszélyeinek       (feltételezett)      okairól      keretes
          cikkrészletünkben     írunk    bôvebben    (""Veszélyek    a
          háttérben").  A  SuperStor--HyperDisk  páros  háttéríráskori
          konfliktusa  (amit  szándékosan  idéztünk  elô,  de bármikor
          elôfordulhat,  például  áramkimaradáskor)  miatt megsérült a
          röptömör  meghajtó,  több  file  olvashatatlanná vált, s ami
          kínosabb,  a  SuperStor  többszöri javítási kísérlet után is
          csak  olvasásra volt hajlandó megnyitni a röptömör meghajtót
          (túl  óvatos  volt ôkelme, de nem lehetett meggyôzni errôl).
          A  Stackerrel háttérírás melletti lefagyasztáskor két teljes
          könyvtárfát  vesztettünk  el.  Az Xtradrive-nál (egy korábbi
          cikkben  már  említettük  ezt  a  röptömörítôt) a CHKDSK-kel
          (látszólag) helyrehozható hibákat kaptunk.

          Az  Xtradrive  esete  azonban hosszabb bemutatást igényel. A
          röptömörítôket     szélsôséges     körülmények    közt    is
          megvizsgáltuk.  A  röptömött  lemez  teleírásakor  a Stacker
          ""disk  full"-t  (a lemez megtelt állapotot) jelez a lemezre
          író  programnak.  A SuperStor ugyanezt teszi: ha a tényleges
          tömörítési  arány  (mondjuk  1,8:1)  nem  éri  el  az  elôre
          beállított  értéket  (mondjuk  3:1), akkor látszólagos ""bad
          cluster"-eket  jelez,  amiket  legegyszerûbben  a  @KCHKDSK /f@N
          paranccsal  tüntethetünk  el  (nem  valódi hibáról van szó).
          Az  Xtradrive  azonban  nekiáll automatikusan áttömöríteni a
          lemezen  lévô  file-okat.  Ez rendkívül lelassítja a lemezre
          írást,  de  újabb  Mbyte-ok  férnek  a  merevlemezre,  s  ha
          lassabban is, folytathatjuk a munkát.

          Nos,  ha a háttérben írás is be van kapcsolva, kínos helyzet
          állhat  elô.  Amikor  az  Xtradrive  már  nem  képes  tovább
          tömöríteni  a file-okat, végül mégiscsak ""megtelt" üzenetet
          küld,   de   immár  nem  ott,  ahol  a  tényleges  telítôdés
          bekövetkezett.  Cache-programja  válogatja, hogy ilyenkor mi
          történik.  A  Norton  Cache  (6.0)  lefagyott  (szegény  ezt
          teszi   írásvédett  lemezeknél  is).  A  HyperDisk  üzenetet
          küldött  a  képernyôn,  ""Retry"-t  választva  az  Xtradrive
          nekiállt    tovább    tömöríteni,    persze    sikertelenül.
          Végeredmény:  bár  a  HyperDisknek  adott ""Abort" válasz és
          újraindítás  után  a  lemez  ellenôrzéskor  rendben  levônek
          tûnt,  de nem sokkal késôbb kiderült, hogy több file belseje
          ""kinullázódótt",  vagyis  0 értékû byte-okkal íródott felül
          (legalábbis  ilyen  tartalmat  jelzett  az  Xtradrive).  Egy
          másik  alkalommal  --  ez már nem a háttérben írás témájához
          tartozik,  de  az Xtradrive-ról szólva egy ízben csak annyit
          írtunk,  hogy gondjaink voltak vele -- véletlenül töröltük a
          C:   gyökérkönyvtárát   (pontosabban   @K[F5]   Copy@N   helyett
          @K[F6]  Move@N  mûveletet   végeztünk   rajta  Norton  Commander
          alatt).  Sebaj,  visszahoztuk az adatfile-okat, s pótoltuk a
          rendszerfile-okat.  A  gép  nem  bootolt,  az  Xtradrive azt
          üzente,   hogy  hiányzik  az  operációs  rendszer.  Gyerünk,
          segít  a  DOS  SYS.COM-ja!  Azonban a SYS.COM eszközmeghajtó
          által  kezelt  meghajtóra nem hajlandó feltenni az operációs
          rendszerhez  tartozó  file-okat,  így a gép továbbra is csak
          floppyról volt indítható.

          A    sikertelen   próbálkozások   után   letelepítettük   az
          Xtradrive-ot.  Látszólag  rendben lefutott minden, de eltûnt
          a   C:  meghajtó  --  úgy  látszott,  hogy  a  gépben  nincs
          merevlemez.  Az  FDISK úgy látta, hogy a merevlemezen idegen
          (például  más  operációs  rendszerhez tartozó) partíció van,
          neki  ahhoz  semmi köze, nem nyúlhat hozzá. Más particionáló
          programok  ugyan  nekiláttak eltávolítani az Xtradrive által
          ""felrakott"  speciális  partíciót,  de sikertelenül. Maradt
          az   alacsony   szintû   (hard)   formattálás.   Ennyit   az
          Xtradrive-ról  (és  azokról  a  merevlemez-gyártókról,  akik
          megtiltják  a  vincsijeik hardformattálását -- eddig még nem
          volt   gondunk   belôle,  de  egyik  ismerôsünk  jelezte:  a
          hardformat  egy  @Krégi@N,  általa  már  elfelejtett típusú, NEC
          gyártmányú IDE vincsit agyonvágott).

          Az  Xtradrive-nak  mégsem ezeket a -- könnyen elkerülhetô --
          hibáit   érzem   súlyosnak,   hanem   lassúságát   (legutóbb
          bemutattuk   teszteredményeit).   ""Kiveszi  a  lóerôket"  a
          merevlemezbôl  -- ezt készítôi is érezhették, nem véletlenül
          nem   telepíthetô   XT-kre   (ezt   a  programkód  sebessége
          semmiképp  nem  indokolja,  a  286-osra  írt programok -- ha
          csak  az  utasításokat optimálják, s nem használja a program
          a  védett  üzemmódot  --  legfeljebb  10%-kal  gyorsabbak  a
          8088-on, 8086-on is futó megfelelôiknél).

          Figyelem!   A   Stacker   3.00-ról   szóló  cikkünk  óta  új
          tapasztalatokat  szereztünk a programmal. Komoly problémával
          találkoztunk.   A  röptömörített  lemezeken  lévô  programok
          közül   több  használhatatlanná  vált.  Az  MS  DOS  SYS.COM
          programja  például  ""Not  enough memory" üzenetet küld, nem
          hajlandó  mûködni  (pillanatnyilag  617|632  byte  szabad  a
          DOS-memóriából).  A Norton Utilities DS.EXE (Directory Sort,
          könyvtárrendezô)   programját  indítva  többnyire  ""Reading
          error  drive  C:"  üzenetek  jönnek,  s  ezt  követôen  más,
          egyébként  gond  nélkül  mûködô programok is indíthatatlanná
          válnak,  hasonló  hibaüzenettel  -- például a COMMAND.COM. A
          COMMAND.COM   lecserélése   sem  segített.  A  gép  többször
          lefagyott.   A   CONFIG.SYS  Stackert  indító  sora  nálunk:
          @KDEVICEHIGH=C:\STACKER.COM     /P=1     C:\STACVOL.DSK@N.     A
          szokásos  lemezvizsgálatok  (Stacker-féle CHECK.EXE, CHKDSK,
          Norton-féle  NDD.EXE)  semmiféle  lemezhibát nem jeleznek, a
          hibásnak    tûnô    programok   lecserélés   után   ugyanúgy
          viselkednek,  vírus  jelenléte  nagyon  nagy valószínûséggel
          kizárható.   Kizárásos   alapon   a   Stacker  SDEFRAG-jának
          újratömörítésére  (SDEFRAG  /R)  gyanakszom:  úgy emlékszem,
          mielôtt lefuttattam volna, még nem jelentkeztek a hibák.

          Azóta  befutott  a Stacker 3.00 egyik újabb alverziója, jött
          valami  SuperStor  Pro  kezdemény  is (nem a teljes csomag).
          Bemutatjuk  ôket,  kipróbáljuk rajtuk mindazt, amit érdemes.
          Megjelent  az  Xtradrive 1.10 verziója is, ez sem hiányozhat
          majd a mezônybôl.


           @VÉrtékelés@N

          Látható,  mennyire  érdekes  programcsomag a SuperStor 2.00.
          ""Aktivizálja"  a  felhasználót,  aki  --  ha  megbirkózik a
          furcsaságokkal  --  nagyon  jó  kis programot használhat. De
          amíg  ezt  eléri, jónéhány cifra káromkodást megereszthet...
          Módosítanom   kell   korábbi   kijelentésemet,  miszerint  a
          röptömörítôk   kigyógyultak   volna   gyermekbetegségeikbôl.
          Kinôtték ôket, de újabbakban szenvednek.

          Igazán  részletesen  csak  a  Stacker és a SuperStor egymást
          követô    verzióit    vizsgáltuk.    A   többi   röptömörítô
          sebességben,  megbízhatóságban  elmarad  tôlük  --  bár ez a
          helyzet    gyorsan   megváltozhat.   Az   eddigiek   alapján
          leszûrhetjük,  hogy a Stackert könnyebb kezelni, a SuperStor
          dokumentálatlansággal   és   kellemetlen  hibákkal  terhelt.
          Hibáit  kiismerve  elôtérbe kerül sebességfölénye, de akinek
          ez  a legfontosabb, szerintem maradjon a ""csupasz" DOS-nál.
          Ugyanez  áll  az  adatbiztonság  szempontjából  is  (lásd  a
          ""bithiba"  témakörét).  Még  egy  tanács: a SuperStor mellé
          érdemes  kioperálni a DR DOS-ból az UNDELETE-et, megelôzendô
          a   kétségbeesést   (hogy  az  AddStor  miért  nem  kérte  a
          SuperStor  licencdíja  mellé  az  UNDELETE  használati jogát
          annak idején a Digital Researchtôl, az rejtély).

          A  röptömörítôkkel  foglalkozó  cikksorozatunk  ezzel  véget
          ért.  Az  alapokat  tisztáztuk.  A  témára legközelebb akkor
          térünk  vissza,  amikor  elkészül  az  röptömörítôk  és  más
          programtípusok  Eurotesztje  --  ami  néhány  hónapon  belül
          várható.  Akkor  majd  átfogó, táblázatos értékelést adunk a
          piacon eddig megjelent röptömörítôkrôl.

          @KBérces László@N


           @VKöszönet@N
          Ezúton  mondunk  köszönetet  a  Keszo Kft-nek, hogy lehetôvé
          tették számunkra a SuperStor programcsomag tesztelését.



           @VTendenciák, avagy merre röpül az idô vasfoga?@N

          A  Stacker  1.00,  1.10 és 2.0x még -- jó rendszerprogramhoz
          illôen  -- a parancssoros vezérlést részesítette elônyben. A
          3.00  már  orrba-szájba  ablakoz,  @Kfor  Windows@N-nak  hirdeti
          magát,  s  tömörített EXE file-jai ellenére jó 2 Mbyte-os. A
          SuperStor  2.00  megmaradt  600  Kbyte  alatt, de -- fogadni
          mernék  rá  --  elirigylik  a Stacker vindózos szépségeit, s
          nem   elégszenek   meg   az   (árnyékolt,   óh!)  karakteres
          ablakokkal.    Jönnek    majd    az    @Kikonos     --egeres@N
          @K--átméretezhetôablakú       --görgetôsávos     --ikonléces@N
          @Kkattintsitt--kattintsott                 --kattintskétszer@N
          @K--fogdmegspottyantsdlemásutt@N    élvezetek,     miközben  a
          felhasználónak  kell  kitalálnia, hogyan oldhat meg alapvetô
          feladatokat. Miért van az,  hogy  a szépség hajhászása már a
          rendszerprogramokat is elérte?!



                           @VVeszélyek a háttérben@N

          A lemezcache-programok  használata ""csupasz"  DOS lemezeken
          sem   teljesen   veszélytelen.     Addig,   amíg   csak    a
          lemezolvasást  gyorsítjuk  velük  (""write through", ""write
          off" üzemmód),  nincs semmi  veszély. A  mai cache-programok
          kivétel  nélkül  felkínálják  a  további  gyorsítást   ígérô
          ""write  back",   ""staged  write",   ""write  on",   Norton
          Cache-nél  ""IntelliWrite"   +  ""/DELAY"   vagy   ""/QUICK"
          beállítást.     A   háttérben   írás   ""bevetése"   azonban
          veszélyes,  mivel  ilyenkor  az  írási mûveletek nem szigorú
          sorrendben   történnek,   hanem   a   cache   program  által
          átcsoportosítva, s persze késleltetve.  A gép  írásmûveletek
          közbeni  lefagyásakor  ""csupasz"  DOS  lemezeken   ilyenkor
          többnyire  helyrehozhatók  a  hibák,  általában csak file-ok
          sérülnek  meg   (vagy  maradnak   köztes  állapotban).     A
          röptömörítôk  azonban  egy  újabb  réteget terítenek a lemez
          fölé.   Az   írások  átcsoportosítása,  késleltetése   immár
          (legalább) négy területet érint: a röptömörített,  virtuális
          lemez   könyvtárait   és   adminisztrációs   területeit,   a
          tömörített  file-okat  tároló  mesterséges  (a   röptömörítô
          által belügyként kezelt) clustereket, valamint a  merevlemez
          tényleges tartalmát. Az ebbôl fakadó lehetséges  sérülésekre
          még egyik röptömörítô sem készült fel.



                             @VMérési eredmények@N

          A két vezetô  röptömörítôt vizsgáltuk sebesség  és tömörítés
          szempontjából.

                                 @VTömörítés@N

          E  teszthez  a  röptömörített,  virtuális  lemezeket hordozó
          file-okat  úgy  készítettük  el,  hogy  82  millió  byte-nyi
          helyet  foglaljanak  el.  A  Stacker  3.0-val  82|001|920, a
          SuperStor   2.0-val   81|999|872   byte-os   hordozó  file-t
          sikerült  készíteni,  hajszálpontos  egyezést  nem   tudtunk
          elérni még átméretezéssel sem.

          A  röptömör  meghajtókra  ezután  298  könyvtárban lévô 4810
          file-t másoltunk  fel (az  MS DOS  5.0 és  a Windows 3.1 itt
          csak kis részt foglalt el..., s rengeteg szövegfile is  volt
          a  mintában),  amelyek  összmérete  103|918|611  byte  volt,
          tömörítés nélkül 129|499|136 byte lett volna a  helyigényük.
          Röptömörítve  72|304|640  (Stacker  3.0), illetve 74|935|808
          byte  (SuperStor  2.0)  volt  a  helyigényük.   A  4810 file
          egyike  sem  volt  tömörítve  hagyományos  tömörítôvel (ARJ,
          PKZIP stb.),  a (megtalált)  tömörített COM-okat  és EXE-ket
          is  kibontottuk,  de  egyre  több program használ tömörítést
          saját file-jai  kezelésekor, fôleg  a játékok  és a kövérebb
          programcsomagok.   Az  eredményen   ez  is  meglátszik.    A
          Stackernél  maximális  tömörítést  (/P=9)  állítottunk be (a
          SuperStornál   nincs   mit   állítani),   majd   a   file-ok
          felmásolása  után   újratömörítettük  a   teljes   virtuális
          lemezt.   Utóbbi  mûveletnél  a  SuperStor  további  mintegy
          4%-kal,  a  Stacker  3.0  0,4%-kal  nyomta  össze  a felvitt
          anyagot.

          Érdekesen alakul a tömörítési  arány és a lemezen  megmaradt
          szabad hely kijelzése.  Lényegében ahány program,  annyiféle
          értéket   kapunk.    A   SuperStor   a   virtuális  meghajtó
          létrehozatalakor  megadott  tömörítési  aránnyal  szorozza a
          @Kfizikailag@N   megmaradt   szabad   helyet,   s  ezt jelzi ki,
          mint várható szabad helyet.   A Stacker az addig  tapasztalt
          tömörítési aránnyal  szoroz. A  DOS, a  Norton Commander  és
          más  programok  ezektôl  eltérô  értékeket  közölnek,  végsô
          soron  leginkább   a  röptömörítôk   saját   statisztikájára
          támaszkodhatunk.   Ezek alapján  SuperStor alatt  81|999|872
          --  74|935|808  =  7|064|064,  Stacker  alatt  82|001|920 --
          72|304|640  =  9|697|280  byte  maradt  szabadon. Tömörítési
          arányként (74|935|808 / 129|499|136 stb.  alapján)  42,1%-ot
          (SuperStor),  illetve  44,2%-ot  (Stacker)  kaptunk, avagy a
          röptömörítôknél   szokásos   számítást   használva    1,73:1
          (SuperStor),     1,79:1     (Stacker)     arányt.        Még
          kézzelfoghatóbban:  egy  100 Mbyte-os merevlemez  kapacitása
          (látszólag) 173, illetve 179 Mbyte-ra tornászható fel e  két
          röptömôvel  --  az  általunk  használt  file-minta esetén. A
          ""Tömörség  mindenek  felett!"  elv  híveinek  tehát érdemes
          lehet a Stackert választani a SuperStor helyett.


                                 @VSebesség@N

          A  tömörítés  vizsgálatakor  a  (fokozott tömörítést elôíró)
          @K/P=9@N     kapcsolóval     futtattuk     a     Stackert,     a
          sebességtesztben   viszont   a   (gyorsabban   futtató) @K/P=1@N
          kapcsolót   használtuk.     Négy   jellegzetes    géptípuson
          futtattuk     a     teszteket:     486/33     +     cache-es
          merevlemez-vezérlô, 386DX/40,  386SX/20 laptop,  286/16 MHz.
          Táblázatunkban  csak  a  lemezsebességre  jellemzô   tesztek
          eredményét  mutatjuk  be.   Kiderítettük  a   Stacker--dBase
          ellentét  okát:   a   dBase-program  @KRUN TIME 00@N  parancsára
          fagyott le a Stacker 2.00 és  a 3.00 is.  Ezt kiiktattuk,  a
          lefagyás  megszûnt,  s  a  minta-adatbázist generáló program
          futásidejét  is  ""bevettük"  a  tesztbe.   A  dBase   teszt
          idôtartama ezért lett minden esetben hosszabb a  szokottnál.
          A  zárójeles   összehasonlításnál  a   DOS  alatti    mérési
          eredményeket 10|000-nek, a  három szám összegét  (DOS-nál ez
          30|000  volt)  ismét  10|000-nek  vettük,  a  többi   oszlop
          számait  ehhez  viszonyítottuk.   îgy  tehát végeredményként
          súlyozás nélküli arányszámokat kaptunk (a nagyobb értékek  a
          jobbak).

          A költözéskor  sajnos eltûnt  a leggyorsabb  és a leglassabb
          gépen  végzett  tesztek   eredménysora,  de  arra   pontosan
          emlékszem,  hogy  semmi  meglepô  nem  volt  bennük,  a  két
          középsô  gépéhez  nagyon  hasonló  eltéréseket  mutattak   a
          Stacker és a SuperStor között.  A 33 MHz-es 486-os gépen  és
          a  laptopon  megnéztük   a  @K/MAXDBUF=8@N kapcsoló  hatását is.
          Megdöbbenésünkre   a   lemezsebességre   különösen  érzékeny
          dBase-tesztben  a  SuperStor  így   gyorsabb  volt  a   sima
          DOS-nál! Ha  nincs elég  memória, a  MAXDBUF értéke kisebbre
          is állítható, 2  feletti értékeinél úgy  is gyorsabb lesz  a
          SuperStor, mint alaphelyzetben.

                                 @V386DX/40@N

          @Vteszt (s)  DOS      Stacker 3.0, /P=1  SuperStor@N
          compiler     63.83    73.05              74.78
                       (10000)  (8738)             (8536)

          dBase        176.42   415.01             214.12
                       (10000)  (4151)             (8239)

          DOS          80.68    98.92              97.32
                       (10000)  (8156)             (8290)

          összesítés   (30000)  (21045)            (25065)

          @Varány      (10000)  (7015)             (8355)@N


                              @V386SX/20 laptop@N

          @Vteszt  (s)   DOS      Stacker  3.0, /P=1  SuperStor  SuperStor, /MAXDBUF=8@N

          compiler     116.72  129.30             133.33     121.49
                       (10000) (9027)             (8754)     (9607)

          dBase        399.14  801.63             461.64     304.23
                       (10000) (4979)             (8646)     (13120)

          DOS          110.56  143.35             142.97     150.21
                       (10000) (7713)             (7733)     (7360)

          összesítés   (30000) (21719)            (25133)    (30087)

          @Varány       (10000)  (7240)              (8378)      (10029)@N